Feedback clase 27 febrero

Hora inicio: 10:30

Hora finalización: 14:30

Lugar: Aula H1.10

Asistentes:

- Paula Peña
- Iñigo Ruiz
- Adrian Romero
- Ramón J. Guerrero
- Aitor Rodríguez
- Eduardo Pizarro
- Jesús Zambrana
- Francisco M. Villalobos
- Carlos Varela
- Horacio Garcia
- Juan José Gómez
- Fernando Fernández
- Raúl Montalbán

Grupo 5

- No se ha resumido el análisis de competidores. (Se comentó la semana pasada). Tampoco aparece la confirmación
- No se muestra el rendimiento por miembro del grupo
- Como se va a gestionar a los usuarios pilotos.
- No se muestran la Landing Page en las diapositivas poner al final el qr de la landing page
- Poner planificación siguientes Sprint
- Hablar de lo que ocurre si se producen retrasos o problemas.
- Todo lo que se dice a final de clase, tiene que estar en una lista de comprobación al final de la presentación.
- Buen opener.
- Decir cual es el minimo a dar para que la ONG de su visto bueno.
- Debe decir de donde sale el porcentaje del rendimiento.
- No se ha respetado el orden que dieron los profesores al final de la clase (facilita dar el feedback de los profesores).
- Indicar en qué ha afectado el problema de la BD.
- Landing Page y competidores siempre se pone.

Grupo 2

- Buena presentación.
- Como vamos a usar la encuesta referente a los problemas encontrados para afrontarlos.
- Buena gestión de usuarios pilotos.
- Que nos quedemos con los 3 primeros del analisis de competidores. (Hemos hecho un analisis de 9 pero nos centramos en ...)
- Estimación de minutos del github actions.
- Opener no muy efectivo. (Meterle drama)
- Elevator tiene que estar.
- Costes de mantenimiento (lo puesto no es mantenimiento, lo puesto es coste de operación).
- Tener en cuenta el orden de la presentación.
- En el análisis de competidores indicar cual es la característica killer.

Grupo 6

- No decir tanto la muletilla "a grandes rasgos".
- Un poco rápido, cuesta saber que se va a contar/el hilo
- No sigue el orden recomendado dado la semana pasada.
- Mucho tiempo perdido en explicar el DAFO.
- No se ha hablado del porcentaje de tareas que se llevan hecho para este sprint.
- No se deja claro lo que se va a hacer en cada sprint.
- No se ha mostrado el análisis de riesgo.
- Se confunde con el MVP (hay que comenzar con lo que va a hacer que la aplicación triunfe).
- Hacer la presentación como si fuese la primera.
- ROI, el objetivo mensual es muy alto.
- Elevator: en 1 minuto tienes que convencer de que vas a conseguir el ROI.
- El moderador que se ponga al lado del presentador, no en la banca sentado.
- Mal commitment agremment. Mezcla el rendimiento con el agremment (el invertir 10 horas no supone haber realizado las tareas).
- Especificar las tareas.
- Se ha mejorado la presentación respecto la semana pasada.

Grupo 4

- Muy buen inicio efectivo.
- Usar micrófono.
- Falta de elevator.
- Especificar el otros en usuarios pilotos.
- Falta la planificación de como van a trabajar con los usuarios pilotos.
- Sacar estadísticas (donde pone que hace falta 10000 usuarios).
- Acuerdo (que haya un acumulado, es decir, una semana hace un 80% si la próxima semana hace un 120%)
- Decir que tareas se han hecho y en que grupos (que así se puede priorizar -> diagrama de Gantt)
- Resumen de la retrospectiva en vez de poner etiquetas (destacar lo más importante).
- Propuesta de mejorar -> decir como se va a medir.
- Análisis de rendimiento -> última columna con triángulos verdes hacia arriba y triángulos rojos hacia abajo.
- Valorar Demo en directo o grabada.
- Hacer test cercano a su implementación, no al final del proyecto.
- Decir si se ha realizado algo respecto a verlo en el docsaurios.
- Hace falta hablar de % en los datos. Por ejemplo sacarlos del INE.
- Indicar si alguien quiere un 10 u otra nota.
- En la diapositiva 29 no se lee el texto.
- Argumento de que la web es lenta es débil.
- TCO Mensual.
- Responsable de cada tarea.

Grupo 1

- No suspirar tan alto presentando.
- Buena sintetización del contenido.
- Muy buen feedback tomado
- Buen killer opener.
- TCO. Decir para cuantos usuarios está pensado.
- No se ha hablado sobre la estrategia de documentación.
- Análisis de cuanto tarda según la capacidad (saber cual es el límite de cuota).
- Gráfica con el resumen del rendimiento de cada miembro del equipo.
- En la diapo 34, mejora obtenida en el tiempo.
- No poner el DAFO.
- Poner porcentaje respecto a los distintos análisis
- Mejorar el análisis de rendimiento.
- Ver si es mejor gitflow o goldenflow.

Grupo 3

- Análisis de competidores, poner una linea para diferenciar los 2 tipos de los que hablan.
- Explicar bien porque no existe esta empresa antes (y dejarlo en 2-3 palabras clave).
- Presentaciones muy cargadas (fondos más sencillos).
- Unificar colores en las diapositivas.
- Diagrama de clase (no UML pero dejar claro que representa). Si expresa el modelo del CORE, llamarlo así, no diagrama de clases.
- Buen killer opener.
- Disfrutar más de la exposición.
- Hay que presentarse.
- Gráfica con el rendimiento, agradecer a las personas que hayan trabajado muy bien (solo en caso positivo, no en los contrarios).
- Buena forma de poner los resultados de la retrospectiva.
- Destacar y dejar claro cuales son los porcentajes de personas que dicen que es mala organización y buena organización.
- Ajuste de colores de letras con el fondo.
- Se han dejado las tareas más importantes de la aplicación para despues. Hay que empezar por el Core (lo que te diferencia del resto de aplicaciones).
- Que las Demo se vean mejor.
- Buen complimiento commitment individual.
- De los problemas encontrados, no se ha hablado como se ha actuado ante a ellos.
- Buena planificación de la gestión de usuarios pilotos, pero ponerlo en un calendario.

Comentarios generales

- No confundir el producto minimo viable. Dar prioridad al uso Core.
- TCO. El objetivo que se quiere es que si se tiene en doble de usuarios, como va a afectar.
- Plantear los minutos de las github actions (que tipo de licencia se necesita).
- Commitment agremment, preguntar si todos los miembros del grupo quieren optar al 10. Dejar claro quien es el responsable de cada tarea (dejarlo por semana).
- Tener un orden claro en las presentaciones.
- Dejar claro las diapositivas que se hayan modificado respecto la semana pasada.
- El elevator.
- Indicar el responsable de cada tarea.

Tareas

- Plantear los minutos de las github actions (que tipo de licencia se necesita).
- Interpretar correctamente los dashboard (para el rendimiento de los compañeros...).
- Estructura de la presentación: 15-20% de introducción, demo del final del Sprint 1, retrospectiva de lo hecho en el sprint 1, gestión usuarios pilotos, planificacion siguiente sprint, uso IAs.
- Introduccion:killer opener, elevator, resumen competidores, resumen TCO (capex y opex), situacion actual respecto al esperado (gráfico), estimaciones a corto (4-6 meses) y largo plazo (1-2 años) de costes y beneficios (pesimistas, realistas y optimistas),equipo con roles, estado de cumplimiento del agremment. 15%
- Demo del Sprint 1 (uso de casos Core). 15%
- Retrospectiva del sprint 1. 40% (Gráfica con los miembros del equipo, con cada uno), resultado de la automatización del software (codacy), riesgos y problemas encontrados, lecciones aprendidas, reloj de avance del proyecto (tiempo y presupuesto). Estado del cumplimiento del commitment y evaluación de rendimiento
- Gestión de usuarios pilotos (cuando, cuanto tiempo, como va a ser el feedback).
- Planificación específica del sprint 2 y lo que nos quedaría para el sprint 3.
- Uso de IAs.
- Ultima transparencia con QR y correo de comandos o forma de contactar.

Otras anotaciones

• Próxima semana evaluación. 15 minutos de presentación. Test de teoria. Asistencia obligatoria. Orden aleatorio.